​ 这是《软件过程与管理》这门课程的个人总结，突然很有感触便写了很多，也顺便传到这里，以后可以看看。最近事务颇多，不胜烦扰，加之勇士近况过于惨烈，心情可以说是乌云密布看不见希望了。不过到这里一切总算结束了，输了亦是一种解脱，配一首轻松的Vibe，希望明天会更好吧。

​ 当然，明天必然会更好，因为不会更差了（苦笑）。

收获

对敏捷开发有所理解

​ 第一次接触敏捷开发是在上学期的软件项目管理中，老师在介绍了瀑布模型、增量模型、迭代模型等广为人知的开发模式后，顺便提到了敏捷开发，并介绍了其快速制作Demo不断迭代的特性。这勾起了我的注意，并赶紧拿起手机进行了一番搜索，也许从此我的心中便种下了敏捷开发的种子。

​ 在拿到万维公司的项目开发文档后，对其中的Scrum很是陌生，便直接在官网阅读了其指南，辅以数篇Scrum案例和介绍，对Scrum有了基本的认识。之后的作业过程便是对Scrum指南不断重复的过程，二十多页的指南被我反复翻看、反复理解，从标准分析到和万维公司的Scrum对比再到最后的改进Scrum模式设计，我对Scrum，或者说敏捷开发的一个子集，算是有了相当的了解。

​ 那么什么是敏捷开发呢？在我的Scrum式理解中，我认为敏捷是一种快速地“转身”，快速的拥抱变化、响应变化，正如在一次橄榄球的死球中，每一个人员、每一只开发团队都处于高度纪律化、高度灵活的状态，为了争球而奋勇拼搏。敏捷开发以更加全面特别的描述——Demo，来替代详尽的文档，以个体之间的互动替代严谨的流程和工具，以敏捷转身、拥抱变化替代遵循变化。这样，便也造就了敏捷开发更加轻量、更加灵活，更加易于对抗风险的特性。

​ 敏捷开发的实施又如何呢？我想情况可能并不如文章中描述的那样顺利。在过程设计时，我所虚构的公司首先使用了原始的敏捷Scrum框架。但随着设计的深入，我开始不断思考原始Scrum指南中那些不言自明的内容和前提在现实、在中国软件行业这个大环境下，一定是成立的吗？既然Scrum Master的职责如此重要，那么为什么国内大多公司的Scrum规范对Scrum Master的描述却如此含糊不清，春秋笔法呢？既然Scrum在诸多Scrum Master笔下的案例中大放异彩甚至拯救了公司但又为何在很多开发人员的口中却相当不堪呢？苦思冥想，最终只能对使用的Scrum框架进行了修改。这主要源于两个问题：第一，Scrum的开发团队是一种跨职能、自组织的团队，每种职能员工数目极少，这对每位员工的素质都提出了相当高的要求。然而现实往往并非如此，新人该如何在Scrum团队中自处的问题，便成为了Scrum的桎梏。第二，高难度的策略游戏总是对民心提出了要求，而在编写软件过程管理文档时却总是下意识地对笔下的员工有所忽视。员工们在想什么，这往往是规范编写者忽视的，但它却直接体现在了产品质量上。因此团队建设、会议设计还有很多细节都应该认真斟酌。

没有一成不变的软件开发模式

​ 在软件过程设计的总结中，我表达了“没有一成不变的软件开发模式，真正优秀的软件开发模式永远是动态的、不断吸收其他模式优点的混合模式”的观点。尽管这可能是一句实质意义上的废话，但却确实地体现了我对于从Scrum到Scrum of Scrums再到LeSS和SAFe沧海桑田式演变的感触。最终的LeSS规则，其体量和专业名词数目远超原始Scrum指南，数度让我怀念Scrum指南的友好。而复杂至LeSS，却也远远不是终点，或者说也只是一个起点。从简单的做一些人员规划、产品梳理到对多支团队的架构优化再到对规模化企业的复杂性、混乱度进行优化和管理，过程管理和人类的规模化组织的发展是相适应的，也许永远不会停下。

管理有时候真的比代码重要

​ 做了近三年的代码人员，或者说开发团队中的一颗“螺丝钉”，这回总算看到了不一样的风景，而这片风景却让我对管理的理解有了翻天覆地的变化。也许很多代码人员，也许是未毕业的代码人员，对管理人员、过程设计人员、文档编写人员有一种本能的偏见，毕竟最终的产品来自我的代码下，和他们的关系有着多重间接。但真正虚拟地成为了一回过程设计人员，对文档中以文字形式存在的似乎没有生命的所谓开发团队中的诸位开发人员，没有了丝毫的尊敬，甚至只有对人数过多的厌恶。因为人数越多，带来的管理成本的增长远高于能带来的贡献的增长。设计一个更加高效的、更加灵活的过程，这种宏观上的贡献远大于每一位代码人员对产品的贡献。这样宏观看来，高效的管理和有效的过程优化，确实比微观上的一行行代码要重要。当然，前提是它真的高效和有效。

感受

​ 持续了近一个月的大型文档项目终于结束了，作为团队中的一位文档制造机，制造出来的上万的文字不断升华着我对敏捷、过程、管理等概念的理解，也对于我未来选择走向哪一条道路有所启发。感谢这门课程。